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PUBLIC MEETmCS OF F.I.C 



STAFF 



The Forth Int«r«»t Croup 1» pl««ie«l to 
announce a public «eetlng eeri**. Wo will 
meet on the fourth (I) Saturday of th« Bonth 
in Hayward. Ca.. tn the Special Evonta Roo» 
of the Liberty Houae Departaent Store. In tho 
Southland Shopping Center (800 Southland H«ll) 

This room la on the third floor rear. The 
fornal meeting begins at 1:00 PM, but we 
ftathcr for lunch about 12 Noon. 

The specific dates are July 28, Aug 25, 
Sept 22, Oct 27, and Nov 2«. A single tech- 
nical topic will be presented In detail, with 
workahop sessions on the flg-FORTH nodel, and 
any topics of Immediate intcrcat. In July, 
Dave Lyons will present the ascll acmory duap 
of Forth which Is psrt of his 6800 version. 
This Forth program shows the entire language 
map on one sheet of paperl 



The volunteer staffing of Forth Olaenslons 1« 
a bit 'fluid. For this Issue, our staff con- 
sisted of: 



EDITOR 
REVIEW 



Bill Ragsdale 
Dave Boulton 



CONTRIBUTORS Paul Bartholdl 
D. U. Borden 

TYPESETTING GLC Secretarial 
and Vydec 

ARTWORK Anne Ragsdale 

CIRCULATION 6502 TIM and Perscl 



PUBLISHERS COMHENTS 

The Issues of Forth Olaenslons h«v« 

been scheduled for two month Intervals, but 
have been at Intervals determined by the over- 
all activities of the steering coaalttee. 
In the past aonths we have participated In th« 
International Standards Tcan, given conf«r«ac« 
papers the Fourth West Coast CoapuCer Falrc, 
attended the Forth Users Meeting in Otrecht, 
Holland. 

These eventn have been outwardly reflect- 
ed In the large gap alnce Issue 3. For the 
near term, hope Is In slghtt. Ve have Isaoe 
3 ready for publication In three weeks, and 
Issue 6 should occur within a aonth. This will 
wrap up Voluae I. At this tlae we will 
evaluate our efforte, and plan for future 
actfvitlee. Member coaaent will be quite 
apropos during this period and will help 
shape future application of effort- 
Thanks are due the aeaberahlp for their 
patience during this period. 



HISTORICAL PERSPECIVE 

FORTH was created by Mr. Charles H. 
Hoore In about 1969 at the National Radio 
Astronoay Observatory, Charlottesville, VA . 
It was created out of this d t ssa t Isf ac t t on 
with available prograaalng tools, especially 
for autoaatlon. Distribution of his work to 
other observatories has made FORTH the 
de-facto standard language for observatory 
•ucoaatioo. 

Nr. Moore and several »t»ociate» formed 
Forth, Inc. , In 1973 for the purpose of 
licensing and support of the FORTH Operating 
Systea and Prograaalng Language, and to supply 
application prograaalng to meet customers' 
unique requlreaents. 

FORTH enjoys a synerglsa of Its features. 
It has none of the elephantine character- 
istics of PL/1 or FORTRAN. It has a density 
and apeed far surpaaslng BASIC, but retains an 
interactive nature during program development. 
Since It le extensible, special words are 
easily defined to give It the terseness of 
APL. Its clarity and conalstency result froa 
being the product of a single mind (as were 
APL and PASCAL) . 

Although the language specification and 
aany iapleaentatlons are In the public domain, 
aany other lapleaentatlona and application 
package* are available aa program products of 
coaaarclal vcndora. 

The Forth Interest Croup Is centered in 
Northern California, although our membership 
of 450 is world-wide. It was formed In 1978 
by local Forth programaers to encourage use 
of the language by the Interchange of ideas 
through acalnars and publlca t lona . All effort 
!• on a volunteer basis and the group Is 
affiliated with no vendors. 

:S Fic 
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THE " TO" SOLUTION 



Paul Bartholdi 
Observatolre De Geneve 
CH-1 290-Sauverny 
Switxerland 



OLD : 



NB4 



fit the Catalina standardization meeting. 
Chuck Moore suggested rapidly the "TO" 
construct to aleviate some, if not all, of 
the difficulties associated with address 
manipulation. This new construction seems 
to me extremely powerful. It should con- 
siderably decrease the number of errors and 
improve the readability of programs. It is 
very easy to understand and to use (much 
easier in fact than the constructs It is 
replacingi). Its implementation is also 
trivial but the lack of experience In using 
it may hide some difficulties. These notes 
try to sketch its potentials. 



1. The 



TO 



concept 



The basic concept is the following: The 
code associated with VARIABLES is divided 
into two exclusive parts. 



i) A 9 B 9 C ! 
il) P I* G D- H Dl 

iii) X W Y P« F* Z PI 



3. VARIABLES or CONSTANTS ? 



A B + TO C 
P G D- TO H 
X Y F* TO Z 



Some advantages of the new concept are 
quite evident from the previous examples. 
Just before the Catalina meeting, I came to 
the conclusion that variables should be 
dropped altogether. If A , B , ... Z had 
been constants in the previous examples 
then, using P and 1 , the three lines would 
have been coded 



i ) 
ii) 
iii) 



A B 
P G 
X Y 



+ 

D- 
P« 



C 
H 
Z 



j 

D! 
Fl 



- The first one (or " fetch code ") is 
identical with the one associated 
normally with CONSTANT . It pushes on 
the stack the value (byte, word or 
words) in the parameter field. 

- The second one (or • store code ") is 
new. It transfers the value (byte, 
word or words) from the stack into the 
parameter field, it is equivalent to 
<vari able-name > ! (or CI or D! 
or Fl ). 

The choice between the two codes depends on 
a state variable (which will be called IVAR 
hereafter) that has two possible states: 
^ (or fetch state) and 1 (or store state). 

If %VAR - the first code is executed 
and %VAR is unchanged. 

If %VAR - 1 thj second code is executed 
and % VAR is immediately returned to 9. 



The operator " TO " sets %VAR to 1, 
forcing the next-called variable to store 
the content on top of the stack in its 
parameter field instead of fetching it. 

2 . Examples using * TO " 

Me suppose three single variables called 
A , B and C three double variables P , G 
and H , and three floating variables X , Y 
and Z . Then the following half-lines are 
equivalent. The first column assunes the 
old definitions of variables, t^ie second one 
uses the new concept. 



which Is already better than the "old* above. 

The difficulty starts with ARRAYS. If 
they push values onto the stack instead of 
addresses, then it becomes much more diffi- 
cult to store values at the right places. 

Note that • C (or H or Z ) takes two 
words but is really, at execution time, 
a single operator ( LIT <address-of -C> ) . 
" TO " is then the shortest solution in 
terms of memory space, and more or less 
equivalent to the CONSTANT solution in terms 
of the time used. 



4. The " address " problem 

But the main advantage of " TO 
context are the following: 



in this 



- In the general sense a " CONSTANT " 
should be used as such, and never (or hardly 
ever) be changed. In particular it may 
reside in PROM . I suggest then to keep the 
constants as such, its associated code 
ignoring the value of tVAR . We then 
should redefine the variables to check %VAR 
and behave accordingly. 

- One of the main unresolved points at 
Catalina was the definition and use of 
addresses for variables in the general 
sense. One consensus was obtained in 
September at the Geneva meeting, that is, 
as far as possible, addresses should be 
omitted. The " TO " concept solves this 
requirement admirably. No addresses are 
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ever put on the stack, or manipulated 
explicitly. Then byte or word addressing is 
irrelevant. It is taken care of at the 
system level only, in the code of the second 
part (the "store code"). 

5 . Portabi 1 ity 

Because of this, FORTH proqraais become 
more portable. " TO " replaces all fetch 
and store operators which would or would not 
be distinct, which would work on byte or 
"position" or word addresses. Transporting 
a program from a micro to a large CDC 
implies now much less adaptations. 

6 . Clarity - security 

Using less operators, in fact the strict 
minimum, is probably one of the best ways of 
improving clarity. Note also that * TO * 
appears as an infix operator to the program- 
mer (and reader!). In terms of security, " 
TO ' implies that only the parameter field 
of variables can be changed. Other addres- 
ses are not (at least directly) accessible. 

This is certainly a tremendous gain for 
some environments. 



7. The ARRAY problem 

The use of " TO " with ARRAYS Is not as 
simple as with variables, but still quite 
practicable. Note first that anything but a 
variable can stay between " TO " and the 
variable's name. If C is defined as an 
ARRAY (with the double associated code) 
then 

A TO 4 C (Instead of A 9 4 C I ) 
DO I TO I C LOOP 

(instead of DO I I C I LOOP ) 

are quite alright and extend all the pre- 
viously noted advantages of " TO ". But the 
programmer must take care that the Index 
must not contain a variable . For example: 

4 TO B ... A TO B C 

will put the value of A into B Instead 
of into C The necessary form should then 

be 

A B TO C 

which is surely less pleasant because of its 
asymmetry. 

8. Fetching and storing inside a disk bloclc 

The problem extends of course to "virtual 
arrays" like the disk blocks. In this 
context, direct access should be considered 
separately from Data Management. The double 
code concept associated with • TO " should 
be extended to the Data Management opera- 
tors. For the direct manipulation of data 
inside a disk block, I suggest the creation 
of a new operator, with the double code, 
associated with the form of 

<relat 1 ve-word-addre«a> 
<bloc-number> BLOC 
P«ge 39 



( BLOC is of course just a provisional 
name J ) 

Example : 

4 . 12 BLOC 5 + TO 5 12 BLOC 

Instead of 

12 BLOCK DUP 4 ♦ « 5 + 
SWAP 5+1 

or 

12 BLOCK 4 + ? 5 + 12 
BLOCK 5*1 

9 . Ge neral access to the (whole) memory 

No good FORTH programmer would ever 
accept to be strongly restricted in hi* 
access to the memory. But If the • TO " 
concept is really accepted, then all the 9 
and I operators should disappear. I 
suggest, instead, to add (its usage could be 
restricted) a generalized array called 
MEMORY (or any equivalent) with once more 
the double code associated with It. 
Then <addres8> MEMORY would either fetch 
from or store into the real address. 

As an example, we would have 

H TO 15317 MEMORY instead of 
(f 15317 I or 

DO I MEMORY S. LOOP Instead of 
DO I 9 S. LOOP etc. 

MEMORY is clearly equivalent to 9 and 
I depending on IVAR. 

10. Generalization of address matching: 
virtual arrays 

The previous points 8 and 9 suggest a 
further generalization that may solve 
another problem we have had since the 
beginning of FORTH: the use of arrays 
as parameters for a procedure. It was 
generally solved by putting the address of 
the first element on the stack, and doing 
explicit address arithmetic in the procedure 
(see the FFT of Jim Brault for example). 
This is certainly neither clean nor fast. 

What I propose Is the following: A 
virtual array ( VARRAY , DVARRAY , 
FVARRAY , CVARRAY etc.) behaves like an 
array, but does not reserve space, except 
for a pointer to the real array. The link 
between the virtual and any portion of 
the memory is established by the word 
HATCH 

For example; 

^f9 ARRAY CUSTOMER 
1fl0 ARRAY STAR 

VARRAY NUMBER 
, CUSTOMER MATCH NUMBER 

associates the real array CUSTOMER with the 
virtual array NUMBER . 

Then <1> NUMBER will be equivalent to 
<i> CUSTOMER. 
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ReMMber that, as previously, 

<i> NUMBCR pushea the valu* of the 
l'** STAR or CUSTOMER on the stack. 

and <«> TO <1> HOMBER will store <■> Into 
the l'** STAR or CUSTOMER . 

At any tl«ie, CUSTOMER can be replaced by 
STAR , (and vice versa) by 

■ STAR NATCH NUMBER 

in this way, MEMORY Is defined by 

VARRAY MEMORY 
9 MATCH MEMORY 

>8 PB 



SCR f ISO 

( Exaapla of the creation of TO ) 

1 HERE . CONSTANT ZVAR 1 ZVAR SET TO 

2 : VAR CONSTANT ;CODe IHB, XVAR LSA, 

3 AO IF. B I) LDA. PUSH. 

4 ELSE, CLA, ZVAR STA. S) LOA. B I) STA. POP. 

5 THEN. 

6 : DVAR CONSTANT . :CODE INB , ZVAR LDA. 

7 AO IF. 8 LOA. DSP. A I) OLD. S) STB. PUSH. 

8 ELSE. CLA. ZVAR STA, ..T STB. S) DLD, 

9 ..T I) DST, POP.. 
10 THEN, 

It i ARRAY CONSTANT DP *\ :CODB INB, t) AOB, ZVAR LDA. 

12 AO IF, B I) LDA. PUT. 

13 ELSE. CLA, ZVAR STA. 

U SI) LDA. B I) STA, POP., 

IS THEN. 

SCR # ISl 

I 2ARRAT CONSTANT DUP ■*■ I* DP -fl 

1 :CODB INB, S) ADB, S) ADB, ZVAR LDA, 

2 AO IF, B I) DLD, S) STB, PUSI, 

3 ELSE, CLA, ZVAR STA, . .T STB. 

It ISP, S) DLD, ..T I) DST. POP., 

5 THEN, 

6 I VARRAT CONSTANT ;CODE IHB, B t) LDB , S) ADB, ZVAR LDA, 

7 AO IF, B I) LDA, PUT, 

8 ELSE, CLA, ZVAR STA, 81) LDA, B I) STA, POP, 

9 THEN 

10 : DVARRAT CONSTANT :CODE IHB, B I) LDB, S) ADB, 8) ADB. 

U ZVAR LDA, AO IF, B I) DLD, 8) STB, PUSH, 

12 ELSR, CLA, ZVAR STA, ..T STB. 

13 ISP, S) DLD, ..T I) DST. POP.. 

14 THEN, 



15 PORTB 



IMP 



: NATCH 



I 



IMP 



Pauls' esaBpl* of tha use of TO will be prasaatad la the aast Issue 
of Forth Dlaenalons. It utlllica Kauths' •nmmpla for the calculation 
of the dates of Eaatar. 
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FORTH IMPLEMENTATION PROJECT 



In June of 1978, the Forth Intere»t Croup 
held Its' first public aeetlng. With only 
mlmlmal publicity, we had In excess of 40 
people attend. We had Intended to offer 
educational assistance In using Forth. 
However, we found everyone was enthuslastle 
to learn Forth, but only five had access to 
running systena. 

FIG then surveyed for vendor availability 
of the language. We found there were numerous 
ml n 1-coop u t er versions at educational and 
research Institutions, all directly decended 
from Mr. Moore's word at NRAO. Of course. 
Forth, Inc offers numerous commercial systems. 

None of these systems were available for 
personal computing. It appeared unlikely that ' 
this need would be met In the foraeeable 
future. Our conclusion was' that a suitable 
model should be created, and transported to 
Individual micro-computers. Thus was born the 
Forth Implementation Team (FIT). 

This team was proposed aa a three tier 
structure. The first tier had several exper- 
ienced Forth systems programmers, who would 
provide the model and guide the lap leae n t at ion 
effort. The next tier was the aoat critical. 
It was coaposed of systems level prograane rs , 
not necessarily having a background In Forth. 
They were to transport the common language 
model to their own computers by generating 
an asaeably language listing that followed 
the model. Their results would be passed 
to the distributors that fora the third 
tier. These distributors would cuscoalze for 
specific personal computer brands. Finally, 
the users could have access to both source and 
object code for maintenance. 

Space doesn't permit Inclualon of the 
FIT project. Itself. The project was detailed 
as one of the six Forth conference papers at 



the Fourth West Coast Coaputer Falre, Nay 1979 
in San Francisco.' [1] The result Is that PIC 
now offers the Installation Hanual with 
glossary and Forth aodel ($10.00) and assaably 
language listings for nuaerous coaputara 

($10.00 «) Included aret 8080, PDP-11, 
PACe. 9900, 6800. and soon 6502. and Z-80. 

(tote that FIG offers these listings which 
still have to be edited into aachlne readabla 
fora. custoalred, and assembled for specific 
Installations. We hope that local taaaa 
share the effort and then distribute for 
others. 

Reports of ina t al la t Ions are beginning to 
coae in from the USA and Europe. We sincerely 
hope this work will give a benchaark of qual- 
ity and uniformity that will raise tha 
expectation of all users. 

FIG would like to thank the follovlag 
aeabers of the Implementation Teaa who have 



devoted 
tiae to 



a Major part 
this effort. 



of aloe months' spare 



Dave Boulton 
John Cassady 
Gary Felerbach 
Bernard Greening 
Kin Harris 
John Jaaes 
Osve Kllbrldge 
Dave Lion 
Mike O'Malley 
Bill Ragsdale 
Bob Saith 
LaFarr Stuart 



Instructor 
8080 

Coap. Aut. 

Z-80 

Librarian 
PDP-1 1 
PACZ 
6800 
9900 

Instructor 

6800 

6800 



[11 Bagsdale. WilliaB F. 

"Forth lap leaentatlon. A Teaa Approach" 
The Best of the Coaputer Falrca, Vol IV 
froa: Coaputer Falre ($U.78, USA) 
333 Swett Road. Woodside. CA 9A06Z 



FORTH INTERNATIONAL 

For aeveral years the Forth Users Group 
(Europe) has sponsored a teaa working toward 
a standards publication for Forth. The 1977 
meeting (Utrecht> produced a working docuaant 
FORTH-77. Attendees included European 

educational institutions and Forth, Iqc« 

la October. 1978. an expandad group sat 
at Catallna Island (Calif. ). Attendees 
Included Forth Uaers Group (NcluwenhulgKan. 
Bartholdi). Forth, Inc. (Moore. Rather. 
Sanderson). FIG (Jaaes, Boulton, Ragadale. 
Harris), Kltt Peak (Miedaner. Goad. Scott), 
U of Rochester (Forsley). SLAC (Stoddard), and 
Safeguard Ind. (Vurplllat). 

The document resulting froa this four day 
meeting has been released as FORTH-78. This 
document la becoming a good reference guide la 
evaluating the consistency and completeness of 
particular Forth systems. It Is available 
froa FIST to participating aponaora. (Sea 
b a 1 ow . ) 

A aajor benefit of the teaa meeting was 
the development of close communications 
Page ♦! 
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STANDARDS TEAM 

bataaan major uaers. For example. FIG la 
learning from the multi-tasking of U of R, 
Kltt Peak and Utrecht ara running fig-FORTR, 
and we have adopted the securlt7 package 
plooaarcd in Europe. None of theac eventa 
would have been likely without the contacta 
begun at Catalina> 

The Team haa announced tbe next Standarda 
Meattng for October 14 thru 18. 1979, again 
at Catallna. The teaa agreed on an orglnii- 
ational budget of $1000.00, to be met by $30. 
contrlbuitions by aponaora (individuals and 
compaalea ) . 

Theac funds will be used solely to defray 
organizing costs of the annual meeting and 
distribution of the working doeumenta to 
participants. Thoaa conaidarlng participating 
should become Team Sponsors by remitlng aa 
given below. Sponsors will receive the just 
ralaaaed FORTII-78, and all Teaa mailings. 

Please remit to FIST. XCarolyn Roaenbarg, 

Perth. Inc. SIS Manhattan Ave., Manhattaa 
Baacb, CA 90266. 
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FOKTH DIMENSIONS 

P.O. Box HQS 

San Carlos, CA 94070 



Dear Sir: 

I was somevhac disconcerted when I read the article by Mr. 
David J. Sirag. "DTC Versus ITC for FORTH on the PDP-11", 
FORTH Dimensions, Volume I, No. 3. The author haa , I be- 
lieve, misunderstood the intent of the article by Mr. De- 
war. 

In Mr. Dewar's article, the definitions of direct threaded 
code (DTC) and indirect threaded code (ITC) are 

"DTC involves the generation of code (my em- 
phasis) consisting of a linear list of addres- 
ses of routines to be executed." 

"ITC. . ." (involves the generation of code con- 
sisting) ". . .of a linear list of addresses 
of words which contain addresses of routines 
to be executed." 

As applied to the FORTH type of helrarchal structure (Heir- 
archal Indirect threaded code?), I would extend Mr. Dewar's 
definition to be 

"ITC involves the generation of code con- 
sisting of a linear list of addresses of 
words which contain addresses of routines 
to be executed. These routines may them- 
selves be ITC structures." 

However. Mr. Sirag based his conclusions on the following 
loose definition: 

"The distinction between DTC and ITC as 
applied to FORTH is that in DTC executable 
machine code is expected as the first 
word after the definition name; while, in 
ITC the address of the machine code is 
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expected. " 

Obviously the two men are not referring to the same things. 
Mr. De««tr Is referring to the list of addresses which define 
the FORTH word, while Mr. Sirag is referring to the impl- 
mentatlon of the FORTH interpreter. If Indeed Mr. Sirag' s 
statement were true (which it is not) that their "analysis 
contradicts the findings of Uewar", then they should have 
Implemented a DTC language rather than the ITC language of 
FORTHI Indeed, a careful examination of what Is actually 
occurlng In LABFORTH reveals that their techniques are lo- 
gically Identical to Oevar's ITC. They have simply, through 
clever programming, taken advantage of a particular Instruc- 
tion set and architecture. It is beyond the scope of this 
letter to prove this equivalence, or to support the FIG 
desire to have a common implementation structure for all 
versions of FIG FORTH. 

Please note that I am not quibline over semantics with Mr. 
Tlrag. All definitions are arbitrary. (However, the value 
of a definition lies in its consistency, precision, and 
useability. I find Mr. Sirag's definition of DTC and ITC 
to be inconsistent with the environment in which he ope- 
rates, FORTH, and thus quite useless.) My intent Is twc 
fold: (1) I am a self appointed defender of the excellent 
work of Mr. Dewar, and (2) I want to correct any misconcep- 
tions concerning this Issue for readers of this newsletter 
who did not have access to Dewar's (better) definition of 
DTC and ITC. 



Sincerely , 

Jon F. Spencer 
President 

Pascal Computing Services, Inc. 
14011 Ventura Blvd., Suite 201E 
Sherman Oaks, CA 91403 
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poly. FORTH BY FORTH, INC 



Because of its speed and economy, FORTH 
Inc.'s FORTH language has been favored by 
many mini and mierocofuputer designers. Now 
comes polyFORTH, which combines the best 
features incorporated in the mini and micro 
vers ions . 



language with 
, basic arith- 
in a 512-byte 
"words* (com- 



PolyPORTH is a multilevel 
the essential functions (e.g. 
metic and logic operators) 
nucleus, and user-defined 
parable to macros) in the outermost layer. 
What's more, the standard pac)cage fits in 4 
Icbytes of PROM, with an additional 2 k 
for the assembler and text editor (which 
aren't needed to run a program once it's 
developed ) . 



or mass storage. Other improvements over 
previous versions include faster dictionary 
search, all 16-bit arithmetic and a simpler 
target compiler. 

The target compiler can be used to develop 
a program of a micro-computer development 
system. The compiler code can either be 
executed directly, or be compressed and 
burned into ROM. Scientific routines, a 
data-base management system and applications 
software are available options. 

The 8080 and 9900 are polyFORTH's first 
targets, but versions for the 8086, LSI-11, 
Seriea-I and Honeywell Level 6 are scheduled 
by the Manhattan Beach, CA company for 
release later this year. 



The new operating system goes beyond 
previous FORTH versions by being able to 
handle multitasking and many terminals 
(limited only by the hardware), and by 
including a buffer handler that supports RAM 

January 23, 1979 



Contact Steven Hicks at FORTH, Inc., 815 
Manhattan Avenue, Manhattan Beach, CA 90266, 
(213) 372-8493. 



Dear FIG: 

Having just received your Issue No. 3, it 
seems to me that the "DTC method used by 
Si rag is still "indirect threaded code" in 
the terminology used by Dewar, and should be 
distinguished from other implementation 
methods as being "executed" rather than 
"interpreted." The use of actual machine 
code in place of the code address is the 
"executed" aspect, but only in the case of 
the Low Level Definition (Code) does the 
use of machine code reduce the level of 
indirection in the threading to that of 
direct threaded code. In the Storage 
Definition in .Si rag's diagram, there is 
still a subroutine call in the dictionary 
entry containing data (constant, variable 
type entries). Direct threaded code would 
require this subroutine call to be moved 
from the individual data-Word to the code 
string referencing that word. Whether that 
subroutine call is executed by an actual 
machine language JUMP SUBROUTINE instruction 
or by an interpreter routine Is another 
matter. Now, in the case of the Code type 
dictionary entry, use of executed machine 
code tends to also remove a level of 
indirection because only one jump is needed, 
there being only one address, that of the 
code routine, involved; this coincidence 
unfortunately confuses the two consequences, 
even though they are separate. 

The concept of Threaded Code seems 
inherently fuzzy, because any high-level 
instructions compiled by a translator into a 
series of subroutine calls has the same form 
as threaded code, so it looks like almost 
any compiler is going to use a certain 
amount of threaded code. Some operations, 
however, like adding two numbers, take so 
little machine code that many compilers 
would expand them completely in-line instead 
Page 43 



of threading them in a subroutine, and it is 
at this low level of prinitives that th« 
concept has meaning. Even when a subroutine 
call saves nothing compared to » full 
in-line expansion, going to two subroutine 
calls, i.e. indirect threaded' code, many 
save space by reducing the amount of code to 
Identify the types of the operands being 
processed, ana in some cases it may also 
save time. On a very large computer perhaps 
all the variable types Involved are an 
Inherent part of the machine instruction 
set, and the memory may be tagged to 
identify type there as well, and both the 
questions of e xe cu t ed/ i nt e rpr e ted and 
indirect /direct would not be relevant. If 
one had a machine which executed FORTH 
primitives as its machine language, you 
would still have indirect threaded code, but 
completely executed instead of interpreted. 
The PDP-11 seems to fall in between. 

None of the above considerations, how- 
ever, contradict Mr. Slrag's main conclusion 
that how FORTH is implemented should not be 
part of its definition. 

One final note: in the DTC, ITC com- 
parison for storage definitions, DTC was 
shown having a larger overhead than ITC even 
though the VAR routine appears shorter in 
the DTC case. Even though the space over- 
head is greater, 1 wonder if he has over- 
stated the DTC overhead time. He seems to 
show a single jump-subroutine taking longer 
than an interpreted jump. 

Sincerely yours. 



George B. Lyons 

280 Henderson Street 

Jersey City, New Jersey 07302 



FORTH INTEREST GROUP RO. Box 1105 San Carlos, Ca. 94070 



Nov*«b«c, 1978 



Dear riC: 

I was very excited to find 80»ethln9 from 
you in my mail today, but then I was dis- 
appointed to discover that It was a copy of 
the journal article which Introduced me to 
FORTH and your existence, which 1 already 
have. 

On October second, I sent you a check and 
asked for everything else offered on the 
subscription form (FORTiTDIMENSIONS, Volume 
1, number 1, p. 22.), i.e., newsletter sub., 
glossary, and PORTH-65. And I've been 
anxiously awaiting the receipt of any or all 
of these. 

Of course I realise you're all volun- 
teers, and I'm not angry... but I really 
trould like to get that stuff. I am, like 
many others, I imagine, anxious to get a 
version of rORTR up on my system. I've 
managed to dig up most of the references 



listed In the article (still waiting for 
DECUS) except for the last one: is It in 
priht? 

I also have the documentation for the 
Digital Group's CONBRS and Programma's 
6502FORTH (for the Apple, which I don't 
have). Both of these programs are outer 
interpreters written in assembly language, 
and contain no inner interpreter. Interest- 
ing, and they look like FORTH, but that's 
not really what I want to do... 

Rather than invest another 30 cents in 
postage, I'm enclosing a check for $2.00 
for the reprint — I know these things aren't 
free, but pleaes send the other items soon, 
okay? Thanks. 

Sincerely, Dan del Vecchio 

Ann Arbor. MI 

Editor — 

Apologies to Nr. del Vecchio. We mis- 
handled his entire request, and yet he en- 
closes an extra $2.00i Our mail processing 
is now current. Ne will complete the full 
six Issues of FORTH DIMENSIONS. 



SCR * 3 

GLOSSARr DOCUHENTATI(>N - D.U. BORDEN 

1 AFTER REMIHG W.F.RAGSDALE' S ARTICLE ON THE 'HELP* COHHAMIi 

2 IN FORTH DIHENSIONS NO. 2 AND SOHE PROPAGANDA FROH FORTH INC.t I 

3 UROTtI H SHORT F'ROGKAH WHICH PRINTED OUT EACH FORTH UORD AS IT 

4 IS DEFINED, THE ADDRESS OF THE LENGTH BYTE AND THE ADDRESS OF 

5 THE HARH BYTE. AFTER EACH ENTRY. I PRINTED ELLIPSES TO ALLOW 

6 A HANDWRITTEN ENTRY OF WHAT EACH COMMAND IS SUPPOSEDLY DOING. 

7 THE ADURESS OF THE PARH BYTE IS USEFUL SINCE THAT ADDRESS 

8 APPEARS IN HIGH LEVEL COLON DEFINITIONS "OBJECT" CODE. THUS. IF 

9 YOU HAVE NUT WRITTEN YOUR OWN FORTH SYSTEM. YOU CAN HAND 

10 DISASSEMBLE ( DISFORTH HIGHT BE MORE APPROPRIATE > EACH COHHAND 

11 AND SEE WHAT IT IS DOING. 

12 OF COURSE A DISFORTH PROGRAM COULD BE WRITTEN AND I HAVE DONE 

13 SO, BUT I AM NOT HAPPY WITH ITS OUTPUT FORMAT YET. I ALSO HAVE 

14 WRITTEN A TRACE WHICH PUTS A TRAP IN "NEXT" AND LISTS EACH FORTH 

15 COMMAND EXECUTED. VERY USEFUL FOR DEBUGGING. ;S H/Sl/?? 
SCR « 2 

( GLOSSARY OF FORTH WORDS WITH HEAD AND FARM ADDRESSES ) 

1 VARIABLE CMD < TEMPORARY VARIABLE TO HOLD COMMAND > 

2 : TOPOFPAGE CR CR C CMD HEAD PARM 1 CR i 

3 : UNDERLINE C 3 < 

4 : GLOSSARY TOPOFPAGE CURRENT 9 9 CMD I < GET TOP CMD ADDRESS 

5 BEGIN 

6 CMD e IF CMD Q C9 DUP 80 AND - ( GET COMMAND LENGTH ) 

7 DECIMAL . HEX 4 1 DO ( PRINT COMMAND LENGTH ) 

8 CMD 9 I ^ ( INDEX FETCHED IS 1-2-3 ) 

9 Ce ECHO ( PRINT COMMAND LETTER ) 

10 LOOP SPACE 

11 CMD 9 .H SPACE ( PRINT COMMAND HEAD ADDRESS ) 

12 CMD 6 -t- .H UNDERLINE CR CR ( PRINT CMD PARM ADDRESS ) 

13 CMD e 4 f e CMD I ( PICK UP LINK WITH NEXT CMD ADDRESS ) 

14 ELSE QUIT THEN 

15 AGAIN ; ;S 1/30/79 DWB 
GLOSSARY 



CMD 
8 GLO 


HEAD 
1C2A 


PARM 


9 


UND 


IBEE 




9 


TOP 


IBC9 




3 


CMD 


IBBD 




9 


?TE 


IBAl 





•sample ttg-POKTH 

( 
J 

ECHO EMIT 
.H H. (hex ontpu 



FORTH INTEREST GROUP RO. Box 1105 San Carlos, Ca. 94070 



Dear FIG: 

I have been programming for sixteen 
years, but I only discovered FORTH about two 
weeks agol It was a clear case of love at 
first sight, but I've encountered a really 
sticky problem already. I have seven 
different programs, each runs on my Apple II 
computer, and each claims the name "FORTH". 
Aside from that the only thing they have In 
coraraon are the three verbs, *:*, "j", and 
Beyond that, everything is different. 

My question is: Is there such a thing as 
a "standard" FORTH, and if so, where do t 
find out more about it? The only docu- 
mentation I have rounded up so far is one 
borrowed copy of FORTH DIMENSIONS, and 
two pitifully incomplete "user's guides' 
supplied with two of the versions FORTH I've 
bought. HELP! 

Sincerely, 



Gary J. Shannon 

14 115 Hubbard Street 

Sylmar, CA 91342 

Editor 



M so , have you reviewed Programma Inter - 
national's PET FORTH yet? They told me that 
a new version (1.1) would be out In Nov./ 
Dec, but I'm waiting before buying .. .would 
like your oplnions/recomiaendat ions. 

Best, 



Nark Z imnerman 

Caltech 130-33 
Pasadena, CA 91125 



Bdl tor — 

Programma International's version is not 
recommended by PIG. It has a non-standard 
header (no word length indication) and is 
pure machine code. The inner interpreter 
NEXT is missing as are the critical defini- 
tions >CODB, <BUILDS, DOES>, and BLOCK. 
PROTECT traps execution of compiling words 
outside of colon-definitions. PIG now uses 
7C0MP for this purpose. 



April, 1979 



Mr. Shannon addresses a major problem I 
FORTH uniformity is a major problem. 
Current standards (FORTH-77 and FORTH-78) 
exist but cover only areas of mutual user 
concensus. There are remaining areas %rhere 
definition and/or refinement are needed. 
The FIG Installation MANUAL has a aodel of 
the language offered for public comment 
toward uniformity. He also pin-point 
areas of deviation from FORTH-78 in our 
publ icat ions. ■ 

;98»ict»ig8a9»8tta889»8taaw8 aiMiiMM i i iiw i i imiwtt i KHMKmm 

Dear FIG: 

I have an 8k PET and after reading Dr. 
DobbJ[_s number 28 I called Programma Con- 
suIFants to purchase FORTH. Two weeks later 

I received Itl 

I have been working with PET FORTH now 
for a couple of weeks and am still fascina- 
ted with FORTH although I have some problems 
with Programma's implementation. 

Please sign me up. 

Regards , 

Chris Torkildson 
St. Paul, MN 

December, 1978 



Dear FIG: 

I now have Programma's 6800 FORTH and 
I probably shouldn't complain, however it 
does have some differences with the OECUS 
FORTH (CALTECH FORTH). I think my major 
complaint is with the coding; any con- 
ditional branching is almost impossible 
without a previously aasembl»d listing 
to obtain address displacements. My 
MiKADOS/OS/assembler/di sassembler ) i s 
interactive, single-pats, and fast. I 
haven't figured out yet how to do any 
editing other than backspace and line 
deletion, other than redo the program. 
Also, I have the Felix OSP and recursive 
programs just come naturally; same with 
textual programming - somewhat difficult 
with FORTH. Can recursive work be done in 
FORTH? I don't know as 1 can't find out 
enough from any manual (the only one with 
Programma's Is "lufclm") to answer my 
quest ions. 

My "down* outlook may surprise other 
Figgers, however I am (obviously) not a 
computer scientist but feel that after the 
Dobb's puffery by John Janes and a couple 
of letters to the editor, the simplicity 
and al 1-encompassment have been vastly 
overrated. 

Sincerely, 



Dear FIG: 



The FORTH-65 implementation listing you 
sent is great I I I I'm beginning to understand 
the power and beauty of this language/ 
system, with the aid of it, a Caltech (Space 
Radiation Lab) FORTH manual, and James' 
article in Dr. Dobbs...but there are still 
some items I can't figure out. (One stupid 
question: What is PROTECT , used in screens 
36 and 4S7) 
Page 4S 



Neal Chap ion 
Space #27 

602 Copper Basin Road 
Prescott, AZ 86301 

Editor — 

The above letters Illustrate the nega- 
tive comment we receive about Programma 
Internationals' FORTH. 



FORTH INTEREST GROUP RO. Box 1105 San Carlos. Ca. 94070 



